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Multiple Mode Registration And Payment: Processing 

Related Applications 

This application is a Cont inuat ion- In- Par t of pending 
Application Serial No. 09/749,597, entitled "Technique Of 
Registration For And Direction Of Electronic Payments In Real 
Time", filed December 28, 2000. 

Technical Field 

The present invention relates generally to electronic commerce 
and more particularly to payment service user privileges . 

Bac kg round Art 

Over the past several years an international network of 
networks known as the Internet has become increas ingly popular . 
The Internet allows millions of users throughout the world to 
communicate with each other. To provide users with easier access 
to information available on the Internet, a World Wide Web has been 
established. The World Wide Web allows information to be 

organized, searched and presented on the Internet using hypertext. 

Thus, using the World Wide Web a user can submit a query for 
information and be linked electronically to information of interest 
which has been stored at Web locations on the Internet. Using 
hypertext, a user can also communicate information to other users 
of the Internet. Because of the use of hypertext, the information 
which can be queried and retrieved via the Internet includes not 
only textual information but also information in graphic, audio and 
video form. Web search engines and browsers have been developed to 
make searching and retrieval of information of Interest on the Web 
a simple task. Hence, the Web has made it relatively easy for 
virtually anyone having access to a personal computer or other 
device connected to the Internet to communicate with others who are 
also connected to the network. This ease of use has resulted in an 
increase in the number of users utilizing the Internet. 

With the proliferation of Internet users, numerous services 
are now provided over the Internet. One of the first such services 
to be offered was electronic banking. Electronic banking allows 
banking customers to access their account information and execute 
banking transactions, e.g. the transfer of funds from a savings to 
a checking account, by simply linking to a bank server using the 
Internet to access account information and communicate transfer 
instructions . 

Electronic banking has advanced from this basic consumer-to- 
bank communication to a consumer being able to electronically pay 
bills and make other payment types and fund transfers to others by 
communicating instructions, via the Internet, to a service provider 
possibly distinct from the financial institute maintaining 
deposited or credited funds of a pre-regis t er ed payer. The 
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payments are then made to the payee by the service provider. The 
term "payment" as used herein can include payment of bills as well 
as other payments not based upon bills. Funds from the payer's 
deposit or credit account, i.e. the payer's payment account, are 
5 debited by the service provider to cover the payment. The payment 
by the service provider to the payee can be made in any number of 
ways . 

For example, the service provider may electronically transfer 
funds from the payer's banking account to the payee's banking 
10 account, may electronically transfer funds from a service 
~p{ provider's banking account, to the payee's banking account, may 
£o prepare a paper draft or check on the service provider's banking 
account and mail it to the payee, may prepare an electronically 
Dp printed paper draft on the payer's banking account and mail it to 
jtrf the payee, or may make a wire transfer from either the service 
= provider's banking account or the payer's banking account. 

H; If the funds transferred to the payee are drawn from the 

Uj service provider's banking account, funds from the payer's banking 
y account are electronically or otherwise transferred to the service 
EE) provider's banking account to cover the payment. Further, if the 
payment will be made from funds in the service provider's banking 
account, the payment will preferably be consolidated with payments 
being made to the same payee on behalf of other payers. 

Accordingly, such electronic payment systems eliminate the 
25 need for a payer to write or print paper checks and then forward 
them by mail to the payee. This makes it easier and more efficient 
for the payer to make payments. Payees receiving consolidated 
payments no longer have to deal with checks from each payee and 
therefore can process payments more efficiently. The making of 
30 payments by the electronic or wire transfer of funds provides even 
further efficiencies in payment processing by payees, and it is 
well recognized that making payments electronically can 
significantly reduce the cost of processing payments for both the 
payer and the payee . 
35 A payer must be a registered user of conventional electronic 

payment systems. Registration is required to protect a provider of 
electronic payment services from credit risk. To register a user, 
the service provider typically obtains and validates information 
relating to the user to verify the user's identity and processes 
40 the obtained information to determine if the service provider will 
accept the credit risk of making payments on the user's behalf. 
Registration may be a somewhat simplified process whereby a user 
submits, on-line, information identifying his or her bank account 
and financial institution and his or her identity. This 
45 information typically includes a name, address, phone number, and 
other identifying information, or some variation thereof. Other 
systems require that the potential user supply a voided check from 
the user ' s checking account . 
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Even with the simplified on-line information submittal, the 
payer is not able to immediately direct payments. After submitting 
registration information, the user must then wait for the service 
provider to validate and process the registration information and 
to receive a confirmation that the registration process is 
complete. This confirmation is typically sent from the service 
provider to the registering user via regular mail channels. Due to 
the processing and delivery time, the registering user is not able 
to immediately utilize the services of the electronic payment 
provider. Accordingly, a need exists for a technique whereby a user 
may immediately register and direct payments in a single on-line 
ses s ion . 

A payment service provider benefits from economy of scale. 
That is, the more users a provider services, the lower the cost of 
providing those services. Credit risk processing, by design, 
eliminates potential payers from utilizing the services of a 
payment service provider. These potential payers, or users, may 
have a poor, incomplete, or non-existent credit history. As such, 
a payment service provider may be unwilling to accept the credit 
risk attendant in providing payment services to these potential 
users . 

Current registration techniques also work against economy of 
scale another way . Certain potential users of payment services 
find disclosure of personal credit information unattractive. 
Because current techniques require that credit histories be 
processed, many of these potential users do not utili ze payment 
services. Accordingly, a need exists for a technique to provide 
payment services to potential users, including those with poor, 
incomplete, or non-existent credit histories and those unwilling to 
disclose credit information, while shielding a payment service 
provider from financial risks. 

Introduced above, the larger the number of customers a payment 
service provider services, the more efficiently the payment service 
provider can operate. Some conventional service providers attempt 
to entice potential customers to register by offering reduced 
introductory fees, or other enticements, for providing a payment 
service. Potential customers, to take advantage of these 

enticements, are still required to register. As discussed above, 
many potential users are unable to register due to poor credit 
histories, or are unwilling to register because of the 
unattractiveness of disclosing credit information. Additionally, 
some potential customers are unwilling to register because of the 
time involved, also discussed above. Accordingly, a need exists 
for a technique to entice potential new customers to utilize the 
services of a payment service provider which overcomes the 
inability or unwillingness of potential customers to register. 

Another problem with typical registration techniques is that 
they are "all or nothing" techniques. That is, potential users are 
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either accepted or denied registration, usually based upon credit 
risk processing. Conventional techniques do not provide for 

different levels of service,, or privileges. Accordingly, a need 
exists for a registration technique whereby different users can 
become registered with different levels of service or privilege. 

Objectives of the Invention 

Accordingly, it is an objective of the present invention to 
provide a technique in which the number of users of a payment 
service is maximized while a payment service provider is protected 
from financial risk. 

It is also an objective of the present invention to provide an 
adaptable payment service technique in which a user's privilege can 
vary . 

It is yet a further objective of the present invention to 
provide a technique to entice users to utilize a payment service. 

Additional objects, advantages, novel features of the present 
invention will become apparent to those skilled in the art from 
this disclosure, including the following detailed description, as 
well as by practice of the invention. While the invention is 
described below with reference to preferred embodiment ( s ) , it 
should be understood that the invention is not limited thereto. 
Those of ordinary skill In the art having access to the teachings 
herein will recognize additional implementations, modifications, 
and embodiments, as well as other fields of use, which are within 
the scope of the invention as disclosed and claimed herein and with 
respect to which the invention could be of significant utility. 

Summary Disclosure of the Invention 

In accordance with a first embodiment of the present 
invention, a method for providing payment services via a network is 
disclosed. A system and an article of manufacture are provided for 
implementing the method. The network could be a public network, 
such as the Internet, a private network, such as a local area 
network, or any other type of network, including the public 
switched phone network. 

According to the method of this first embodiment, information 
identifying a network user is received via the network. This 
network user is a potential payer. The information identifying the 
network user could be any one of, or any combination of, the 
network user's legal name, address, mailing address, business 
address, drivers license number, social security number, taxpayer 
identification number, telephone number, or any other identifying 
information. The network user could be an individual, business, or 
other organization. That is, payment services can be provided for 
individuals as well as businesses and organizations. 

A payer status is assigned to the network user . The payer 
status is one of a first payer status and a second payer status. 
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The payer status defines attributes associated with the network 
user when a request to pay a payee on behalf of the identified 
network user is received via the network. 

If the first payer status is assigned, the payment will be 
5 executed, that is, made, whether or not the payee is within a 
defined plurality of payees. If the second payer status is 
assigned, the payment will be executed only if the payee is within 
the defined plurality of payees. Thus, if the network user is 
assigned the first status, the network user may direct that 
10 payments be made on his behalf to any payee. And, if the network 
Ji user is assigned the second status, the network user may only 
direct that payment be made on his behalf to a payee that is 
included in the defined plurality of payees. 
U2 According to one aspect of the first embodiment of the present 

|Tfe invention, the information identifying the network user is received 
= from a sponsor of the network user. That is, the network user does 

T-\ not transmit the identifying information. Rather, a sponsor 
U; transmits the identifying information. A sponsor is an entity with 
pr: which the network user maintains a relationship. A sponsor can be 
p-€ any entity, including, but not limited to, a financial institution, 
a Web portal site, an on-line merchant, a br ick-and-mortal 
merchant, a social or professional organization, or any other 
individual, group, or organization with which a network user may 
maintain a relationship. Beneficially, the relationship does not 
25 have to be maintained via the network. 

According to another aspect, the request is executed, that is, 
made, by a payment service provider. A payment service provider is 
the individual, business, or organization which makes payments on 
behalf of the network user. According to this aspect of the 
30 present invention, the plurality of payees to whom payment can be 
made on behalf of the network user, if the network user is assigned 
the second status, is defined by at least one of the payment 
service provider and the sponsor, as described above. In this 
aspect, the identifying information does not have to come from the 
35 sponsor, though it could. Of these two entities which could 
determine the plurality of payees, only the payment service 
provider could determine the plurality of payees, only the sponsor 
could determine the plurality of payees, the payment service 
provider could determine a portion of the payees and the sponsor 
4 0 could determine a portion of the payees , or the payment service 
provider and the sponsor could, together, both determine the 
plurality of the payees. It should be understood that the network 
user does not determine the plurality of payees. 

According to another beneficial aspect of this first 
45 embodiment, a plurality of payments are executed on behalf of the 
network user. Information associated with each of the plurality of 
payments is stored. Executing a payment on behalf of the network 
user includes a debit to a financial account associated with the 
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network user. The financial account is maintained with a financial 
institution. Preferably the financial account is a deposit 

account, though it could be a credit account, a savings account, 
stored value account, or a brokerage account. The stored 

information associated with each of the plurality of payments 
includes at least one of, but is not limited to, the date each 
payment was executed, the number of payments executed on behalf of 
the network user, and an indication if the debit associated with a 
payment is not honored by the financial institution. It should be 
understood that the debit could be a paper debit, such as a check 
or draft, or an electronic debit. It should also be understood 
that a debit could not be honored by a financial institution for 
several reasons. These include, but are not limited to, 

insufficient funds in the account being debited, incorrect account 
numbers, or an account being closed or declared inactive. 

Especially beneficial, according to a further aspect of this 
embodiment, an assigned payer status can be changed based upon the 
stored information associated with each of the plurality of 
payments directed by the network user. This includes both changing 
from the first status to the second status, and changing from the 
second status to the first status. All or part of the stored 
information, in addition to information not stored, could be 
utilized to change an assigned status. 

According to another aspect of the first embodiment of the 
present invention, a credit risk is determined. The credit risk is 
a risk of loss in making payments on behalf of the network user. 
That is, the network user may not possess or have access to funds 
to cover the cost of the payment. The network user may not possess 
or have access to funds for any of several reasons, which include 
but are not limited to insolvency and fraud. The payer status is 
assigned based upon the determined credit risk. That is, if it is 
determined that there is a great risk of loss in making payments on 
behalf of the network user, the second payer status could be 
assigned. Likewise, if it is determined that there is a low risk 
of loss in making payments on behalf of the network user, the first 
payer status could be assigned. 

In another further beneficial aspect of this first embodiment, 
an assigned payer status can be changed based upon a later 
determined credit risk in making payments on behalf of the network 
user. This includes both changing from the first status to the 
second status , and changing from the second status to the first 
status. That is, the credit risk is determined a second time. If 
the determination is different than the first determination, the 
network user's payer status can be changed. 

According to an advantageous aspect of this embodiment of the 
present invention, the information identifying the network user is 
received during a real-time communication session. As above, the 
information could be received from the network user, or from 
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another entity. As will be understood by one skilled in the art, a 
real-time communication session is an immediate exchange of 
information between two or more entities. The payer status is 
assigned to the network user during the real-time communications 
session. Thus, the assignment of the payer status is immediate. 

In yet another aspect of the first embodiment, the defined 
plurality of payees is a defined first plurality of payees. Also, 
according to this aspect, a third payer status could be assigned to 
the network user. If this third payer status is assigned, the 
payment will be executed only if the payee is within a defined 
second plurality of payees. The network user could be assigned 
this third payer status, and if so, the network user may only 
direct that payment be made on his behalf to a payee that is 
included in the defined second plurality of payees. The first and 
second plurality of payees could be mutually exclusive, or could 
have overlapping membership. 

According to a further aspect, the first plurality is 
determined by a first entity, and the second plurality is 
determined by a second entity different than the first entity. As 
above, the network user does not determine either plurality. The 
first entity could be the sponsor, discussed above. Or the first 
entity could be the payment service provider, also discussed above. 

In a particularly advantageous aspect of this first embodiment 
of the present invention, the information identifying the network 
user includes information identifying a sponsor, discussed above. 
The payer status, according to this aspect, is assigned based upon 
the identity of the sponsor. Thus, a sponsor relationship 

determines the assigned payer status. Thus could be either the 
first or the second status. 

In yet another aspect of this embodiment of the present 
invention, a plurality of payments are executed on behalf of a 
plurality of network users. These users could each be assigned any 
payer status, or perhaps even not any payer status. In any event, 
information associated with each of the payments is stored. The 
plurality of payees is determined based upon this stored 
information. Thus, the plurality of payees is determined based 
upon historical payment data for payments made to each respective 
payee. As discussed above, each of the plurality of payments 
includes a debit. The stored information includes at least one of, 
but is not limited to, information identifying a payee of each 
respective payment, a date of execution of each respective payment, 
and information indicating if the debit associated with each 
respective payment resulted in that debit not being honored by the 
respective financial institution. Any combination of the stored 
information could be used, in addition to information not stored, 
to determine the plurality of payees. It should be understood that 
information associated with payments to all payees, not just the 
plurality of payees, is stored. 
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As an example, a payee who is not included in the plurality of 
payees and who has received many payments, and none of the payments 
resulted in the debit not being honored, could be added to the 
plurality of payees. Or, a payee who is included in the plurality 
of payees, and to whom an excess of payments to that payee resulted 
in the debits not being honored, could be removed from the 
plurality of payees. 

The system to implement this first embodiment of the present 
invention includes a memory, a communications port, and a 
processor. The processor is in communication with both the memory 
and the communications port. The processor could be any computing 
device capable of operating as described herein, including, but not 
limited to, a network server, a mainframe computer, or a personal 
computer. The memory may be any type memory capable of storing 
data, including random access memory, floppy or hard magnetic disk, 
or optical disk. The communications port may be any device capable 
of sending and receiving information via a network. It should be 
understood that the processor could be multiple processors 
operating in series or in parallel, the memory could include 
multiple types of storage, and that the communications port could 
be multiple communications ports, for example to communicate with 
multiple networks. 

In accordance with a second embodiment of the present 
invention, a method for making a payment on behalf of a network 
user is provided. A system and an article of manufacture are 
provided for implementing the method. According to the method, 
information identifying a network user and a request to make 
payment on behalf of the identified network user are received via a 
network. The identifying information could be any of the 

identifying information discussed above, though, preferably, the 
information is a unique user identifier. 

Based upon the received Information, a mode of operation is 
selected. That is, the identity of the network user controls the 
mode of operation. The selected mode of operation is one of a 
first mode of operation and a second mode of operation. 

Similar to the discussion above, if the first mode of 
operation is selected, the request is executed no matter the 
identity of the payee. If the second mode of operation is 

selected, the request will be executed only if the payee is one of 
a plurality of payees. Thus, in the first mode, payment can be 
made to any payee, and in the second mode, payment can be made to 
only predetermined payees. The system to implement this second 
embodiment of the present invention includes at least a processor, 
memory, and communications port, all as discussed above. 

In accordance with a third embodiment of the present 
invention, a method for enrollment in an electronic payment service 
is provided. Here also, a system and an article of manufacture are 
provided for implementing the method. A request to enroll a 
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network user in an electronic payment service is received via a 
network. The enrollment request includes information associated 
with the network user. As discussed above, this request could be 
received directly from the network user, or from another party. 
5 The information associated with the network user could be only 
information identifying the network user, or could be information 
not only identifying the network user, but also identifying a 
financial account associated with the network user such as a 
deposit account, credit account, or stored value account, among 
10 possible types of accounts. Also, the received information could 
C; be information associated with a credit history of the network 
J5t user. Enrollment in the electronic payment service affords a 
F=! network user the privilege to direct the electronic payment service 
5T; to make payments on behalf of the network user. 

£:S The network user is enrolled based upon the received 

^ M information. This basis could include ensuring that information 
Jli has been received, or verifying the received information. A first 
r4 user status is assigned to the enrolled network user. Preferably, 
Q this first user status is assigned to the network user immediately 
Bb upon enrolling the network user, though it could be assigned at a 
time subsequent to the enrollment. A user status defines 

attributes associated with the network user in relation to the 
electronic payment service. 

Subsequent to assigning the first user status to the enrolled 
25 network user, a credit risk associated with making payments on 
behalf of the enrolled network user, as discussed above, is 
determined based on the received information. This determination 
could include analyzing the received information as well as other 
information in addition to the received information. if the credit 
30 risk is determined to be below a predetermined threshold, the first 
user status is changed to a second user status. That is, if the 
risk in making payments on behalf of the network user is low, the 
first user status is changed to the second user status. It should 
be understood that, in this third embodiment, the network user is 
35 always first assigned the first user status. Then, if the 

determined credit risk is acceptable, the first user status is 
changed to the second user status . 

As will be understood by reference to the discussion above, 
with the first user status assigned, a payment will be made on 
40 behalf of the enrolled network user to only one of a plurality of 
payees. The plurality of payees are determined by an entity other 
than the enrolled network user. That is, the electronic payment 
service , while the network user has the first user status, will 
only make payments on the network user 1 s behalf to any one of the 
45 plurality of payees. Whereas, with the second user status 

assigned, a payment will be made on behalf of the enrolled network 
user to any payee designated by the enrolled network user. 

According to another aspect of this embodiment of the present 
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invention, the network user is enrolled and the first user status 
is assigned during a real-time communications session. That is, 
the network user is immediately enrolled and assigned a user 
status. Also according to this aspect, the credit risk is 
determined subsequent to the real-time communications session. 
Thus, in real-time, the network user is enrolled and assigned the 
first user status, then, at a later time, the credit risk is 
determined. Then, depending upon the credit risk determination, 
the first user status may or may not be changed to the second user 
status. In this manner, the network user can become enrolled in 
real time, while the credit risk determination, which may require 
intensive or time consuming processing, can be performed subsequent 
to enrollment . 

According to a further especially beneficial aspect of this 
third embodiment, a request to execute a payment on behalf of the 
network user is received during the real-time communications 
session and the request is accepted for execution during the real- 
time communication session. Thus, the network user can immediately 
enroll and direct payments. It should be understood from the 
discussion herein that if the payee is one of the plurality of 
payees, that accepting for execution also includes executing the 
payment. If the payee is not one of the plurality of payees, the 
payment will be accepted for execution, but not executed until and 
unless the credit risk determination is made and the determination 
results in changing the first user status to the second user 
status. If the determination results in the first user status not 
being changed, the request will preferably not be executed and the 
network user will be notified that the payment will not be 
executed . 

In yet a further aspect of this embodiment of the present 
invention, a plurality of payments are executed on behalf of the 
network user. It should be understood that according to this 
aspect of the invention, the network user could have the first 
user status or the second user status when the payments are 
executed. If the network user has the first user status, the 
payments could all be executed previous to the credit risk 
determination, or the credit risk determination could have resulted 
in no change to the first user status. Also, all the payments 
could be executed subsequent to the credit risk determination. 

Similar to the discussion above, information associated with 
each of the payments is stored. Based upon this information 
related to payments directed by the enrolled network user, a 
payment history status associated with the enrolled network user is 
determined. The payment history status is determined based upon 
payments executed on behalf of the network user. If the payment 
history status is determined to be a first payment history status, 
the first user status is assigned to the enrolled network user. If 
the payment history status is determined to be a second payment 
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history status, the second user status is assigned to the enrolled 
network user. According to this aspect of the embodiment, the 
network user's status could remain unchanged due to the determined 
payment history status, or could change. If the status changes, it 
could change from the first user status to the second user status, 
or it could change from the second user status to the first user 
status . 

According to a further aspect of the third embodiment, 
execution of a payment on behalf of the enrolled network user 
includes a debit, as described above. The information associated 
with each of the executed plurality of payments includes at least 
one of, but is not limited to, the following: information 
indicating if the debit associated with each respective payment 
resulted in that debit not being honored by the financial 
institution; information indicating a number of payments executed 
on behalf of the enrolled network user; and a date of execution of 
each respective payment. 

The system to implement the third embodiment of the present 
invention includes at least a processor, memory, and communications 
port, all as discussed above. 

It will be understood by those skilled in the art that each of 
the first, second, and third embodiments are easily implemented 
using computer software. More particularly, software can be easily 
programmed, using routine programming skill, based upon the 
description of the invention set forth herein and stored on a 
storage medium which is readable by a computer processor to cause 
the processor to operate such that the method of the respective 
embodiment is performed as described herein. 

Brief Description of Drawings 

Figure 1 depicts exemplary networks of the present invention 
and users of the networks, including a processing agent, registered 
users, unregistered users, and financial institutions. 

Figure 2 depicts a computer suitable for use by a registered 
user to access a network in accordance with the invention. 

Figure 3 is an exemplary block diagram of components of the 
computer depicted in Figure 2 . 

Figure 4 depicts a server suitable for use by the processing 
agent in accordance with the present invention. 

Figure 5 is an exemplary block diagram of components of the 
server depicted in Figure 4 . 

Figure 6 is an exemplary depiction of a payments page 
presented to a registered user having the status of a "closed" user 
in accordance with the present invention. 

Figure 7 is an exemplary depiction of a registered user 
database in accordance with the present invention. 

Figure 8 is an exemplary depiction of a payee database in 
accordance with the present invention. 
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Figure 9 depicts communications between the processing agent 
and a registering user to register the user as a "closed" user in 
accordance with the present invention. 

Figures 1 OA— D are flow charts showing operations which are 
5 performed in registering the user as a "closed" user in accordance 
with the present invention. 

Figure 11 depicts communications between the processing agent 
and the registering user to register the user as an "open" user in 
accordance with the present invention. 
10 Figure 12 is a flow chart showing operations which are 

S performed in registering the user as an "open" user in accordance 

with the present invention. 
RJ Figure 13 depicts communications between the processing agent 

m and a registered user to execute a payment on behalf of the 
Cfc registered user in accordance with the present invention. 
^ Figure 14 is a flow chart showing operations which are 

S performed in executing a payment on behalf of the registered user 
r"1 in accordance with the present invention. 

O Figure 15 is an exemplary depiction of a payments page 

M) presented to a registered user having the status of an "open" user 
in accordance with the present invention. 

Best Mode for Carrying out the Invention 

As shown in Figure 1, network 100 interconnects multiple 

25 registered users 110A-110N, multiple unregistered users 120A-120N 
and a processing agent 130. The network 100 is shown to be the 
Internet, but it could be virtually any type of network. Network 
100 could also be multiple interconnected networks. Also shown is 
a network 140 interconnecting processing agent 130 and multiple 

30 financial institutes 150A-150N, each financial institute is 
associated with at least one of the registered users 110A-110N, 
unregistered users 120A-120N, or processing agent 130. The network 
140 is shown to be a private financial institute network, such as 
the currently existing bank network over which it is guiet common 

35 to electronically transfer funds between banks. Here again, the 
network 140 could be another type of network interconnecting the 
processing agent 130 to financial institutes 150A-150N. Also, 
network 140 could be multiple interconnected networks. It should 
be understood that a user, registered or unregistered, may be 

40 either an individual, a business, or other organization. The 
processing agent 130 performs as a payment service provider, 
receiving requests from registered users to make payments on behalf 
of the registered users. The processing agent 130 executes the 
payments as will be described below. 

45 Each of the registered users 110A-110N and unregistered users 

120A-120N is preferably represented on the network 100 by a 
computer of the type depicted in Figures 2 and 3 , which will be 
described further below . However , it should be recogni zed that 
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virtually any network device could be utilized so long as the 
device has sufficient processing and communication capabilities to 
function in the described manner. The term "network device" 
includes personal digital assistants (PDA's) , telephones, including 
cellular and/or digital telephones, and set-top boxes, among other 
devices. It will also be understood that a network device may 
connect to a network via wireless communications. 

Figures 2 and 3 depict an exemplary personal computer suitable 
for use by users, registered or unregistered, to access the Network 
100 in the below-described invention. The computer is preferably a 
commercially available personal computer. It will be recognized 
that the computer configuration is exemplary in that other 
components (not shown) could be added or substituted for those 
depicted and certain of the depicted components could be eliminated 
if desired. 

The computer functions in accordance with stored programming 
instructions which drive its operation. Preferably, the computer 
stores its unique programming instructions on an EPROM, or hard 
disk. It will be recognized that only routine programming is 
required to implement the instructions required to drive the 
computer to operate in accordance with the invention, as described 
below. Further, since the computer components and configuration 
are conventional, routine operations performed by depicted 
components will generally not be described, such operations being 
well understood in the art. 

Referring to Figure 2, the computer 1000 includes a main unit 
1010 with slots 1011, 1012, and 1013, respectively provided for 
loading programming or data from a floppy disk, compact disk (CD) , 
hard disk, and/or other storage means, onto the computer 1000. The 
computer 1000 also includes a keyboard 1030 and mouse 1040 which 
serve as user input devices. A display monitor 1020 is also 
provided to visually communicate information to the user. 

As depicted in Figure 3, the computer 1000 has a main 
processor 1100 which is interconnected via bus 1110 with various 
storage devices including EPROM 1122, RAM 1123, hard drive 1124, 
which has an associated hard disk 1125, CD drive 1126, which has an 
associated CD 1127, and floppy drive 1128, which has an associated 
floppy disk 1129. The memories, disks and CD all serve as storage 
media on which computer programming or data can be stored for 
access by the processor 1100. A drive controller 1150 controls the 
hard drive 1124, CD drive 1126 and floppy drive 1128. Also 
depicted in Figure 3 is a display controller 1120 interconnected to 
display interface 1121, a keyboard controller 1130 interconnected 
to keyboard interface 1131, a mouse controller 1140 interconnected 
to mouse interface 1141 and a modem 1160 interconnected to I/O port 
1165, all of which are connected to the bus 1110. The modem 1160 
and interconnected I/O port 1165 are used to transmit and receive 
signals via the Network 100 as described below. It will be 
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understood that other components may be connected if desired to the 
bus 1110, including communications components other than a modem. 
By accessing the stored computer programming, the processor 1100 is 
driven to operate in accordance with the present invention. 
5 Processing agent 130 is preferably represented on networks 100 

and 140 by a network server of the applicable type shown in Figures 
4 and 5, as will be described further below. However, here again, 
any network compatible device which is capable of functioning in 
the described manner could be substituted for the servers shown in 
10 Figures 4 and 5. 

O Figures 4 and 5 depict an exemplary network server suitable 

for use by the processing agent 130 to access networks 100 and 140 

nj in the below-described invention. The server is preferably a 

jrf commercially available high power, or mainframe computer. Here 

jrfe again, it will be recognized that the server configuration is 
exemplary in that other components (not shown) could be added or 

; r-i substituted for those depicted and certain of the depicted 
components could be eliminated if desired. 

The server functions as described below in accordance with 

£J) stored programming instructions which drive its operation. 
Preferably, the server stores its unique programming instructions 
on an EPROM or hard disk. It will be recognized that only routine 
programming is required to implement the instructions required to 
drive the server to operate in accordance with the invention, as 

25 described below. Further, since the server components and 

configuration are conventional, routine operations performed by 
depicted components will generally not be described, such 
operations being well understood in the art. 

Referring to Figure 4, the server 1000 ' includes a main unit 

30 1010' with slots 1011', 1012 1 , 1013' and 1014', respectively 
provided for loading programming or data from a floppy disk, CD, 
hard disk, and/or other storage means onto the server 10 0 0' . The 
server 1000 r also includes a keyboard 1030' and mouse 1040', which 
serve as user input devices. A display monitor 1020 1 is also 

35 provided to visually communicate information to the user. 

As depicted in Figure 5, the server 1000' has a main processor 
1100 1 which is interconnected via bus 1110 1 with various storage 
devices including EPROM 112 2' , RAM 1123', hard drive 1124', which 
has an associated hard disk 1125', CD drive 1126', which has an 

40 associated CD 1127', and floppy drive 1128', which has an 
associated floppy disk 1129'. The memories, disks and CD all serve 
as storage media on which computer programming or data can be 
stored for access by the processor 1100'. The stored data includes 
one or more databases containing information associated with 

45 registered users 120A-120N and transactions associated with 
registered users 120A-120N. The memories associated with the 
server hereafter will be collectively referred to as memory 1170. 
A drive controller 1150' controls the hard drive 1124', CD drive 
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1126 T and floppy drive 1128'. Also depicted in Figure 5 is a 
display controller 1120 1 interconnected to display interface 1121', 
a keyboard controller 1130 1 interconnected to keyboard interface 
1130', a mouse controller 1140' interconnected to mouse interface 
1141' and a modem 1160' interconnected to I/O port 1165' , all of 
which are connected to the bus 1110'. The modem 1160' and 
interconnected I/O port 1165' are used to transmit and receive 
signals via the Network 100 as described above. It will be 
understood that other components may be connected if desired to the 
bus 1110', including communications components other than a modem. 

By accessing the stored computer programming, the processor 1100 ' 
is driven to operate in accordance with the present invention. 

Once registered, a user is enabled to direct the processing 
agent 130 to make payments on his or her behalf. These payments 
may be payments of bills received from billers, who also may be 
registered users. These bills may be paper bills, or may be bills 
received electronically. These payments may be other types of 
payments, such as payments for goods or services purchased via the 
network 100, or gift payments. 

If a payee is a registered user, a payment is preferably made 
in the form of an electronic debit to a registered payer's demand 
deposit account (DDA) and an electronic credit to the registered 
payee's DDA. Debits and credits can alternatively be made to 
accounts other than demand deposit accounts, such as savings 
accounts, credit accounts and brokerage accounts, among other types 
of accounts. Though, preferably, credits are made to a DDA. Also 
preferably, the electronic debits and electronic credits from and 
to demand deposit accounts are made via the automated clearinghouse 
bank network ( ACH ) , though other networks and other electronic 
means may be used to effect the debits and credits. The debit to 
the payer's DDA can result in a matching credit to the payee's DDA, 
or the debit to the payer's DDA can result in a matching credit to 
the processing agent's 130 DDA. In such case, a separate 

electronic debit is made against the processing agent's 130 DDA, 
with a matching credit to the payee's DDA. This may occur previous 
to, concurrent with, or following the debit to the payer's DDA. 

Funds from the payer's account can also be obtained via paper 
methods, such as by checks or drafts. As well, payments to 
registered users can also be made via paper methods. If the payee 
is not a registered user, the payment to the payee will be a paper 
payment, not electronic. This paper payment may be made to the 
payee in two ways. In a first way, payment is made by a check 
drawn on a DDA belonging to the processing agent 130 and payable to 
the payee. The processing agent obtains funds from the payer's 
DDA. Preferably, this is done electronically, as discussed above. 

Or, funds may be obtained from the payer by way of a processing 
agent 130 prepared draft drawn on the payer's DDA and payable to 
the processing agent 130. In a second way to make payment to an 
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unregistered payee, payment is made by a draft, prepared by the 
processing agent 130, drawn on the payer ' s DDA and payable to the 
payee . 

Figure 7 is a partial depiction of a database 700 maintained 
by the processing agent 130 for storing information associated with 
each registered user. The database includes at least information 
identifying each registered user 701 and that user's status 702. 
Identity information can include any or all information required 
for registration, such as a user name, 701A, as well as a unique 
identifier assigned to each user by the processing agent 130, 701B, 
as is shown in Figure 7 . Those registered users whose status is 
"open" (O) are permitted by the processing agent 130 to direct 
payments to any payee. Those registered users whose status is 
"closed" (C) are permitted by the processing agent 130 to direct 
payments to only certain payees, known as preferred payees and who 
will be further discussed below. Database 700 also may store 
additional information. As depicted in exemplary Figure 7, this 
information can include any or all of, but is not limited to, 
information indicating the date upon which each user registers 703, 
information indicating the number of payments each user has 
directed 704, and the number of those payments which have resulted 
in a debit to the payer not being initially honored 705. Upon a 
user becoming registered, information associated with that user is 
added to database 700. As that user directs payments, the above- 
described information is added to database 700, associated with 
that user. 

Figure 8 is a partial depiction of a database 800 maintained 
by the processing agent 130 for storing information associated with 
payees. Payees included in database 800 include preferred payees as 
well as all payees to whom registered payers have directed payments 
be made. This database includes at least information identifying 
each payee 801 and an indication of status as a preferred payee 
802. Identifying information can include a name, address, and/or 
other identifying information, such as a unique identifier assigned 
to the payee by the processing agent 130. Database 800 may also 
include other information related to each payee. As depicted in 
exemplary Figure 8, the information can include any or all of, but 
is not limited to, information indicating the date upon which a 
payment was first directed to each payee 803, the number of 
payments which have been directed to each payee 804, as well as the 
number of those payments which have resulted in a debit to the 
payer not being initially honored 805. As a payment is made to a 
payee on behalf of a registered user, information associated with 
that payment is added to database 800. This includes adding the 
payee to database 800 if the payee is not already included. 

To direct the processing agent 130 to make payments, a user 
must register. Once a user registers, that user can direct the 
processing agent 130 to make payments on his or her behalf. 
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Introduced above, a registered user can either have the status of 
an "open" user, or a "closed" user. The processing to register a 
user as an "open" user is different than that to register a user an 
a "closed" user. Furthermore, "closed" and "open" registration 
5 processing can be mixed. Thus, the processing agent 130 can 
operate in multiple registration modes. This ability allows the 
processor to offer several registration options. In a first 
option, an unregistered user seeking registration could seek 
"closed" registration, resulting in the status of a "closed" user. 
10 In a second option, an unregistered user seeking registration could 
'"-z seek "open" registration, resulting in the status of an "open" 
f/i user. In a third option, the processing agent 130 could offer 
fy "closed" registration status for free, or for a reduced fee 
compared to "open" registration status, while "open" registration 
'&> status is offered for a fee, or for an increased fee over "closed" 
Z" registration status. This option is especially beneficial in 
increasing the number of registered users. In a fourth option, 
f^i "closed" registration status could be offered to a user for free 
C depending upon a relationship that user maintains with a sponsor, 
5=0 who will be further discussed below. In a fifth option, an 
unregistered user seeking "open" registration status may not meet 
one or more financial risk criterion necessary to obtain "open" 
status, and as a result that "risky" user could be offered "closed" 
status in place of "open" status. Thereinafter, based upon that 
25 user's transaction history, or other factors, his or her 
registration status could be changed to "open" . In yet a sixth 
option, a registering user could initially be registered as a 
"closed" user in a real-time registration process, and 
thereinafter, could be further registered as an "open" user in a 
30 non-real-time registration process. Different ones of these 

options could be presented to different registering users, or could 
be utilized depending upon different circumstances. 

The communications for, and steps of, the registration process 
for registering user 120A as a "closed" user are depicted in 
35 Figures 9 and 10A-10D. As described below, in this and in each 
registration scenario described herein, the registering user 120A 
identifies a single DDA during the registration process, though it 
will be understood that the registering user 120A may identify an 
account other than a DDA, such as a credit account. As shown in 
40 Figure 9, registering user 120A contacts the processing agent 130 
on-line via communication 901. The registering user 120A 

transmits, via the Network 100, at least information identifying 
the registering user 120A, an account number of a demand deposit 
account (DDA) belonging to the registering user 120A, and 
45 information identifying the financial institution at which the DDA 
is maintained, step 1001 of Figure 10A. This information may be 
submitted via an enrollment form transmitted to the registering 
user 120A by the processing agent 130 via the Network 100. The 
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registration information is received by the processing agent 130 
via the network 100, as shown in step 1005. 

Optionally, processing agent 130 can accept more than one 
account from which to electronically debit and/or to which to 
electronically credit, no matter the type registration processing 
(open or closed) being performed. In such a case, registering user 
120A submits information identifying two or more accounts and the 
associated financial institutions. It should be understood that 
whenever a registered user has identified more than one account, 
the registered user may identify the account from which funds are 
to be debited on a per transaction basis, the registered user may 
identify a single account from which all debits are to be made, or 
the registered user may identify a particular account from which 
debits for payments to a specified payee are to be made. When 
receiving funds from other registered users, the registered user 
may identify the account to which funds are to be credited on a per 
transaction basis, the registered user may identify a single 
account to which all credits are to be made, or the registered user 
may identify an account to which credits from a particular source 
are to be made. Furthermore, a registered user may identify a 
single account from which all debits are to be made, and a 
different single account to which all credits are to be made. 

The registering user 120A may be a registered user of another 
type service provider, such as an on-line auction site, a financial 
institution, an Internet portal site, an on-line electronic 
greeting card service, or an on-line merchant. The other service 
provider could present to its members an opportunity to become a 
registered user of the processing agent 130. These other service 
providers are known as sponsors. If a member of another service 
chooses to become a registered user of the processing agent 130 
from an option presented by a sponsor, the sponsor can pre-populate 
an enrollment form with any data that is already maintained by the 
sponsor and that is also required to register with the processing 
agent 130. The registering user 120A completes the enrollment 
form, if necessary, and transmits it to processing agent 130. From 
this point forward, registration via a sponsor is the same as 
registration not via a sponsor. 

In another alternative, a sponsor may interact with the 
processing agent 130 to register a registering user. That is, the 
sponsor presents to the processing agent 130 any required 
information to register the registering user. In this alternative, 
the registering user need not perform any communications with the 
processing agent 130 to become registered. 

Returning to Figures 9 and 10A, at step 1010, the processing 
agent 130 verifies, in real-time, that required registration 
information has been provided, and then stores the received 
information in memory 1170 via communication 905. If all required 
information has been provided, processing could continue with step 
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1020, or either or both of the following operations could be 
performed in real-time. At optional step 1015, the processing 
agent validates the information identifying the registering user 
120A received by the processing agent 130. This too is preferably 
performed in real-time. Required identity information can include 
a name, social security number, mailing address, city, state, phone 
numbers, zip code, date of birth, e-mail address, and driver 
license number, among other information associated with the 
registering user 120A. If the processing agent 130 determines that 
the information identifying the registering user 120A is valid, 
processing could continue with step 1020, or with step 1017. 

The identity validation process can include accessing one or 
more databases 906, via communication 910 containing identity 
information to determine if the received identity information 
corresponds with that in the database (s) 906. As shown in Figure 9, 
database (s) 906 is not stored in memory 1170. However, it will be 
understood that database (s) 906 may be stored in memory 1170. 

At optional step 1017 the processing agent 130 validates the 
received DDA number and the information identifying the associated 
financial institution. If the information identifying the DDA and 
the financial institution is validated, processing continues as 
depicted in step 1020. This too is preferably performed in real- 
time . 

The DDA number / financial institution processing can include 
accessing one or more databases 907, via communication 912, 
containing information associated with demand deposit accounts and 
financial institutions to validate the received DDA/f inancial 
institution information. As shown in Figure 9, database (s) 907 is 
not stored in memory 117 0. However , it will be understood that 
database (s) 907 may be stored in memory 1170. 

It should be understood that optional steps 1015 and 1017 
could be executed essentially concurrently, or step 1017 could 
precede step 1015. Furthermore, only one of these steps could be 
executed in "closed" registration processing. If all required 
Information is submitted, and optionally validated, the processing 
agent 130 generates and stores in memory 1170 a user ID and 
password for the registering user 120A, communication 915 and step 
1020. The totality of the registration information, the user ID, 
and the password can also or alternatively be stored in database 
700. Alternatively, only a portion of this information could be 
stored in database 700. For those users registering from another 
service , an indicator of the service from which the registering 
user is registering is also preferably stored. Database 700, as 
well as database 800, could reside in memory 1170, or could reside 
elsewhere. Optionally, the registering user 120A may select the 
user identifier and/or password. At step 1025, the processing 
agent 130 transmits a notice of completed registration, the user 
ID, and password to the now registered user via communication 920. 



19 



DOCKET NO: 3350-035 PATENT 
CLIENT REF: Portal 



The registering user 120A can now direct the processing agent 130 
to make payments on his or her behalf, albeit only to preferred 
payees. That is, the registering user 120A has become a "closed" 
registered user. 

5 If incomplete registration information has been provided to 

the processing agent 130, following step 1010, at step 1011A of 
Fig. 10B, the processing agent 130 transmits a notice to the 
registering user 120A, or sponsor if applicable, that incomplete 
registration information has been received, communication 925. 
10 This notice could include an indication of the missing information. 
O If the registering user 120A, or sponsor, chooses, at step 1011B 
m additional registration information is transmitted to the 
ITU processing agent, communication 930. This information is received 
m by the processing agent 130, step 1011C, and operations continue 
Cfe with step 1010. 

J" In optional real-time identity processing, if the processing 

O agent 130 cannot validate the identity information, the registering 
^1 user 120A is informed in real-time, via communication 94 0, that the 
O processing agent 130 is unable to register the user, as depicted in 
8b step 1016 of Fig. 10C. The communication also informs the 
registering user 120A that the registering user 120A should provide 
the processing agent 130, via traditional postal delivery, a voided 
check drawn on the user's DDA, along with the information 
identifying the registering user 120A and the DDA and financial 
25 institution information to process the registration in non-real- 
time. Additionally, the information requested from the registering 
user 120A may also include additional information identifying the 
registering user 120A not required for the on-line registration 
process . 

30 In optional real-time DDA/ financial institution processing, if 

the processing agent 130 cannot validate the DDA and financial 
institution information at step 1017, the registering user 120A is 
informed in real-time, via communication 950 that the DDA and 
financial institution information cannot be validated, as depicted 

35 in step 1018A of Fig. 10D. The registering user 120A is also 
prompted to reenter the DDA/f inancial institution information, as a 
possible reason for validation failure can be improper entry of 
this information by the registering user 120A. If the registering 
user 120A reenters and retransmits the required DDA/ f inancia 1 

40 institution information, as depicted in steps 1018B and 
communication 9 60 , the processing agent 130 receives the 
information, step 1018C, and validates the newly received 
DDA/ financial institution information as in step 1017. If the 
registering user 120A does not resubmit this information, or if the 

45 resubmitted information cannot be validated, registration fails. 

The communications for, and steps of, the registration process 
for registering a user as an "open" user are depicted in Figures 11 
and 12 . Preferably, the operations for "open" registration are the 
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same as "closed" registration through step 1017 of Figure 10A, 
except that optional processing in "closed." registration becomes 
mandatory. Thereinafter, the "closed" registration processing 
diverges from the "open" registration processing. However, only a 
5 portion of the optional operations in "closed" registration may be 
made mandatory. Figures 11 and 12 depict these optional operations 
as becoming mandatory. It should also be understood that the 
operations described below for "open" registration could also be 
utilized in "closed" registration processing. In particular, 
10 credit risk processing could be utilized in "closed" registration, 
^r; In real-time "open" registration processing, the processing 

Ca agent 130 makes further determinations relating to the registering 
L::; user 120A in step 1210 of Figure 12. They may be made concurrent 
O with the above-described processing of steps 1015 and 1017, or they 
1=5 may follow, as is depicted in Figure 12. Additionally, though 
these determinations are shown following steps 1015 and 1017, they 
H may precede these steps, or be made between these steps. These 
ihj determinations concern credit risks the processing agent 130 will 
|^ assume in providing the above-described payment service. Credit 
Sb risk processing can include any or all of: evaluating the credit 
history of the registering user 120A, identification of DDA 
closures in the registering user's name, and retrieval of bad check 
history relating to the registering user 120A. 

In this processing, the processing agent 130 determines if one 
25 or more credit risk parameters associated with the registering user 
120A violate one or predetermined parameters. This can include 
setting one or more thresholds and determining if a determined 
credit risk parameter violates a threshold. Credit risk processing 
can include accessing one or more databases 1105, via communication 
30 1106, containing credit related information. As shown in Figure 

11, databases (s) 1105 is not stored in memory 1170. However, it 
will be understood that databases (s) 1105 may be stored in memory 
1170 . 

If all required information is submitted and validated, and if 
35 the credit risk processing does not result in violated credit risk 
parameters/thresholds, the processing agent, at step 1020 of Figure 

12, generates and stores in memory 1170 a user ID and password for 
the registering user 120A. As discussed above, all or part of this 
data may be stored in database 700. At step 1025 of Figure 12, as 

40 above, the processing agent 130 transmits a notice of competed 
registration, the user ID, and password to the now registered user. 

The registering user 120A can now direct the processing agent 130 
to make payments on his or her behalf to any payee. That is, the 
registering user 120A has become an "open" registered user. 

45 If the credit risk processing determines that one or more 

credit risk parameter s /thresholds are violated, registering user 
120A will be denied the registration status of "open". However, 
registering user 120A may nonetheless be accepted as a registered 
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user, albeit with the status of "closed". As will be discussed 
further below, a registered user's status as a "closed" user can 
later be changed to a status as an "open" user. 

In some instances it could be beneficial for the processing 
agent 130 to perform the credit risk processing in non-real-time. 
For example, the credit risk processing may be more efficient when 
performed in a batch mode. No matter the reason credit risk 
processing is performed in non-real-time, a registering user could 
be granted the status of "closed" by way of real-time processing, 
as will be understood from the discussion above, and thereinafter, 
be granted the status of "open" by way of non-real-time credit risk 
processing . 

In this mixed real-time/non-real-time registration processing, 
steps 1001-1025 of Figure 10A are performed, described above, in 
real-time. As in "closed" registration processing, optional steps 
1015 and 1017 may or may not be performed. The registering user 
now has the status of "closed". Subsequent to these steps, and in 
non-real-time, the processing agent 130 performs at least step 1012 
described above and depicted in Figure 12. Assuming that no risk 
processing parameter s /thresholds are violated, the processing agent 
130 changes the user's status in database 700 from "closed" to 
"open" and notifies the user of the change in status . It should 
also be understood that any of the operations to register a user, 
either as "closed" or "open" could be performed as a batch process. 

That Is, some or all of the operations could be performed in non- 
real-time . 

Though not shown in Figures 9-12, the processing agent 130 may 
determine if the DDA associated with the registering user 120A can 
be electronically debited and/or credited during the registration 
process. This determination is preferably made whenever real-time 
DDA/f inancial institution processing is performed. However, it may 
be made in non-real time, such as after a user has registered, 
either as "closed" or "open" . 

A user's status may be changed from "closed" to "open" based 
upon that user's payment history. As introduced above, database 
700 includes information indicating the date upon which each user 
registers 703, information indicating the number of payments each 
user has directed 704, and the number of those payments which have 
resulted in an initial debit to the payer not being honored 705, 
commonly called an exception. Periodically the processing agent 
130 analyzes this information for "closed" registered users to 
determine if any of those users are eligible for a status change to 
"open" . The analysis can include any one or any combination of 
these factors. For example, a user's status could be changed based 
upon the total number of payments that user has directed in 
relation to the number of those payments which resulted in a debit 
to the payer's account not being initially honored. Or, status 
could be changed based upon the length of time that a user has been 
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registered,. perhaps in combination with the number of payment 
directed by that user and/or the number of those payments which 
resulted in a debit to the payer's account not being initially 
honored. As above, the user will be notified of a change of 
5 statu s . 

A user who fails the credit risk processing could also become 
an "open" user if in later credit risk processing, 
parameters /thresholds are not violated. That is, the processing 
agent 130 could, upon a user's request, or periodically, re-perform 
10 credit risk processing for a "closed" user. If the results do not 
O violate parameters, that user's status could be changed to "open", 
^'i If "closed" registration status is granted for free, or a 

jfy reduced fee, a "closed" user could at any time upgrade to "open" 
status. Also, a user who chooses "closed" registration for any 
irib reason could later upgrade to "open" registration. These upgrades 
^ in service levels, as will be understood, are dependent upon the 
O results of credit risk processing for a user wishing to upgrade. 

It should be noted that the number of preferred payees 
2^ available to a "closed" user could be a staggered list. That is, 
EjO the processing agent 130 could offer more than two levels of 
3 service. For example, a minimum cost service could offer the 

narrowest list of preferred payees, while a next higher level 
service could offer a broader list of preferred payees, and so on. 
Finally, in full service, a user would have the status of "open" . 
25 A registered user may have status as a "closed" user because 

of a sponsor relationship that user maintains. That is, a sponsor 
pays for, or otherwise supports, that user's registration. The 
sponsor may change that level of support to include "open" status. 
As will be understood from the above discussion, that user would 
30 still have to undergo credit risk processing to become an "open" 
user unless, as discussed below, special agreement exists between a 
sponsor and the processing agent 130. 

Introduced above, the processing agent 130 may be placed at 
financial risk in making payments on behalf of registered users. 
35 This is especially true when payments are made electronically, or 
otherwise drawn on an account belonging to the processing agent 
130. Credit risk processing ameliorates this risk. The dual "open" 
and "closed" statuses enable users to be accepted as registered 
users even if they are unable to meet the credit risk processing 
40 standards. As discussed above, a user having "open" status can 
direct payments to any payee, while a user having "closed" status 
can only direct payments to preferred payees. When payments are 
made to preferred payees, the processing agent 130 is not placed at 
financial risk, or is placed at only a reduced financial risk. 
45 A payee can become a preferred payee in at least three ways. 

A first way is by agreement between the processing agent 130 and 
the payee. A second way is by agreement between the processing 
agent 130 and a sponsor. A third way is based upon an analysis of 
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database 800. In the first way, a payee agrees to indemnify the 

processing agent 130 against any losses the processing agent 130 

may incur in making payments to that payee. That is, the payee 

guarantees to reimburse the processing agent 130 for any debits to 

5 payer accounts which are not paid by the payers' financial 

institutions. Similar to the first way, a sponsor could agree to 

indemnify the processing agent 130 against any losses the 

processing agent 130 may incur in making payments to one or more 

particular payees. This could include only indemnifying payments 

10 made to the particular payee or payees by certain registered users. 

O The third way a payee can become a preferred payee is based 

JJS upon a history of payments to that payee. Introduced above, 

nj database 800 includes, for each payee to whom a payment has been 

5S made, the number of payments and the number of those payments which 

£5 have resulted in an exception. The processing agent 130 

periodically analyzes this data to determine which of those payees 

p who are not preferred payees are eligible to become preferred 

^ payees. This analysis can include determining if the number of 

O payments made to a particular payee exceeds a given threshold and 

Eb if the number of those payments resulting in an exception exceeds 

lpKE another threshold. This other threshold may be zero. Thus, a 

payee who has an excellent record of payments may be granted the 

status of a "preferred payee" even though that payee does not agree 

to indemnify the processing agent 130. 
25 It should also be understood that a user's status could be 

changed from "open" to "closed". That is, a registered user with a 

history of debits not being initially honored could have his or her 

status downgraded. Also, further credit risk processing could 

result in a status downgrade. And, a change in a sponsor agreement 

30 could also lead to this downgrade. Likewise, a payee status of 
"preferred" could also be revoked. This could be due to an ending 
of an indemnification agreement, or could be based upon the 
processing discussed above. Thus, a payee that receives payments 
which result in an excess of exceptions may have "preferred" status 

35 revoked. This is especially beneficial in those cases in which 
that payee has not agreed to indemnify the processing agent 130. 

A sponsor may not only agree to indemnify the processing agent 
130 from losses associated with payments to certain payees, but may 
also agree to indemnify the processing agent 130 from losses 

40 associated with payments directed by certain registered users. A 
registered user may have status as an "open" user because of a 
sponsor relationship that user maintains. Introduced above, an 
indication of sponsor relationships is stored whenever a user 
registers, whether registration is direct or made on behalf of the 

45 user by a sponsor. A sponsor can agree to indemnify losses 
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associated with certain, or all, registering users who maintain a 
relationship with the sponsor. In such a case, the registering 
user will be assigned the status of "open". 

To aid in understanding the capabi 1 it ies of the processing 
5 agent 130 in making payments, Figures 13 and 14 show the 
communications for, and steps of, the processing agent effecting a 
payment on behalf of registered user 110A. Registered user 110A 
could be making payment of a bill received electronically or via 
traditional delivery means, could be making an on-line purchase, or 
2JD could be making a gift payment, among possible types of financial 
yii transactions. The registered user 11 OA contact s the proces s ing 
agent 130 via communication 1301. During this communication the 
fi registered user provides his or her unique identifier and password, 
zi step 1401. The processing agent 130 receives this data, step 1405, 
JIB and accesses database 700, stored in memory 1170, to determine the 
s _ user's registration status, step 1410 and communication 1310. Via 
i"7'i communication 1315 the processing agent 130 transmits a payments 
yy page to the user, step 1415. 

If the processing agent 130 determines that registered user 
pC 110A has the status of "open", the payments page could appear as 
depicted in Figure 15. The page 1500 includes, at a minimum, a 
field for the user to enter an amount of the payment 1501, and a 
field for the user to enter the identity of the payee 1505. The 
identity of the payee could be the payee's unique identifier if the 
25 payee is a registered user and if the payer knows the payee's 
unique identifier. The page also includes a "submit" button 1510, 
after selection of which the processing agent 130 processes the 
payment directive . 

If the processing agent 130 determines that registered user 
30 110A has the status of "closed", the payments page could appear as 
depicted in Figure 6. The page, as above, includes a field for the 
user to enter an amount of the payment 601. The page also includes 
a list of preferred payees from which the user selects the payee 
605. The list of preferred payees could be presented by various 
35 means, as will be understood by one skilled in the art, including a 
list of names highl ight able by the user, a list including 
selectable icons, each associated with a preferred payee, or the 
list could be in the form of a pull down menu. The page also 
includes a "submit" button 610, as described above. 
40 Following completion of a payments page, at step 1420, the 

registered user transmits the payments page to the processing agent 
130 via communication 1320. At step 1425, the processing agent 130 
processes the payment directive to make the payment on behalf of 
the registered user. Payment can be made by any of the methods 
45 described above, including electronic payments and paper payments. 

The information received from registering user 120A to 
initiate the registration proces s may also include a request to 
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make a payment on behalf of the registering user. For registration 
resulting in "closed" status, if the payee is a preferred payee, 
the processing agent 130 can immediately execute a payment on 
behalf of the user. For registration resulting in "open" status, 
the processing agent 130 can immediately execute a payment on 
behalf of the user no matter the identity of the payee. Thus, a 
registering user can not only register in real-time, but also 
immediately direct payments. Furthermore, as registration is 
preferably performed real-time while a registering user and the 
processing agent 130 participate in a communications session, that 
user may direct a payment during the communications session 
subsequent to receiving registration confirmation with or without 
transmitting or knowing his unique identifier. Also, a user may 
direct a payment without being registered, and without submitting 
registration information. In such a case, the processing agent 130 
will inform the user that the user must register. The payment 
request will be held until registration is completed. Upon 
registration, the request will be executed, of course dependent 
upon the registration status of the user. Thus, the payment 
request may be received previous to receipt of registration 
information . 

It will also be recognized by those skilled in the art that, 
while the invention has been described above in terms of one or 
more preferred embodiments , it is not limited thereto . Various 
features and aspects of the above described invention may be used 
individually or jointly. Further, although the invention has been 
described in the context of its implementation in a particular 
environment and for particular purposes, e.g. in providing payment 
services, those skilled in the art will recognize that its 
usefulness is not limited thereto and that the present invention 
can be beneficially utilized in any number of environments and 
implementations. Accordingly, the claims set forth below should be 
construed in view of the full breadth and spirit of the invention 
as disclosed herein. 



